Hello, everyone, and welcome to today's webinar, Knowledge Management Best Practices for a Successful Customer Support Experience, brought to you by Technology and Services Industry Association and sponsored by Coveo. My name is Vanessa Lucero, and I'll be your moderator for today. Before we get started, I'd like to go over a few housekeeping items. Today's webinar will be recorded. A link to the recording of today's presentation will be sent to you within twenty four hours via email. Audio will be delivered via streaming. All attendees will be in a listen only mode and your webinar controls including volume are found in the toolbar at the bottom of the webinar player. We encourage your comments and questions. If you think of a question for the presenters at any point, please submit through the ask a question box on the top left corner of the webinar player, and we will open it up for a verbal Q and A portion at the end of today's session. Lastly, feel free to enlarge the slides to full screen at any time by selecting one of the full screen button options, which are located on the top right corner of the slide player. I would now like to introduce our presenters today, John Ragsdale, Distinguished Vice President of Technology Research for TSIA Bonnie Chase, Director of Product Marketing for Coveo Dara Perrault, Business System Analyst for OSISoft and Alex Van Fossen, Knowledge Engineer, also with OSISoft. As with all of our TSIA webinars, we do have a lot of exciting content to cover in the next forty five minutes. So let's jump right in and get started. John, over to you. Well, thank you, Vanessa. Hello, everyone, and welcome to today's webinar. We had a huge response to this event, and that is no surprise. Knowledge management has always been one of the top interest areas for TSI members, and it's really one of the few things that is a triple win. It's a win for companies because good knowledge management programs tend to boost productivity, increase self-service success. It's good for employees because they've got the all the knowledge of the world at their fingertips. It boosts their confidence. It makes them look smart in front of customers. We see companies that have, strong knowledge management programs tend to have higher employee satisfaction, as well as lower turnover. And as we all know, happy employees make happy customers. So it's also a win for customers because they're getting streamlined support, much better, lower effort scores for companies with good Kilometers. So very pleased to have Dara and Alex from OSIsoft with us today to share their best practices for knowledge management and how that translates into a excellent customer support experience. So I do a lot of workshops with TSIA members on knowledge management and self-service, and I'm gonna quickly go through some slides today. I'm not gonna spend a lot of time on them, but I really kinda wanna expose you to a lot of the data and research we have on this topic. I collect so much information every year in my knowledge management survey, and not all of it makes it into the state of Kilometers report, that I publish every October. So I'll quickly go through this. You'll get a copy of these slides afterwards. And for those of you who are TSIA members, some of this data is a really interesting way to kind of compare different facets of your Kilometers program to other companies in the industry and identify maybe where you need to up your game a little bit. So why is knowledge management such a hot topic? And it's because people really understand the potential That if you're sharing knowledge as well as you possibly could, it can have a dramatic impact on, employee productivity. And so, in this year's survey, we see that seventy one percent of respondents said that it could boost productivity by twenty percent or more. Forty percent said thirty percent or more. You see eighteen percent said fifty percent or more. So the average, this year was, you know, up a little bit from last year. So people are definitely realizing the potential for knowledge management, but realizing that potential, is where we tend to struggle. And this data is asking companies to rate their employee facing and customer facing Kilometers programs on a ten point scale of one being needs a lot of work and ten being awesome. And as you can see, the scores are not awesome. They are going up a little bit from twenty eighteen to twenty twenty, but we're still in the middle of that scale. So, again, we understand the potential, but we're not realizing that potential. And I'm gonna talk through some of the reasons that companies do struggle, to get the the results that they're anticipating. So, hopefully, you have seen, the knowledge management maturity model. Model. I first published this in twenty seventeen and last year, updated it, with a little little more detail around the strategic phase. But the the point of this is that, you know, companies wanna understand kind of where they are on the continuum of knowledge management and where they can go next. And I kind of see, companies in four phases, the recognition phase where they're really not doing anything, but they have that moment, that something needs to change and we should start investing. The instantiation phase is when you first initially start investing in people process technology, and you typically begin to see results pretty rapidly. And that leads you to the rep, value realization phase when companies start getting really serious about the Kilometers program and the ROI potential, from many different perspectives can be pretty dramatic. And then ultimately, the strategic phase, and this is where we see, Kilometers grow out of support becoming a corporate wide initiative. And for each of these, there are facets around corporate culture, people, process, and technology. So in the annual Kilometers survey, I asked, companies to assess where they are on that maturity matrix. And you can see that from twenty nineteen to twenty twenty, the folks in the the recognition phase and the very few people in the strategic phase, those didn't change very much, but we did see a shift from that instantiation phase into the value realization phase. So that's showing that companies are making some initial investments, and it's starting to pay off. So I'm hoping in the next couple of years, we'll see that seven percent in the strategic phase start to grow a little bit. So I implemented my first knowledge base in, I think it was, nineteen eighty nine. I am that old, and I've been working in and around Kilometers for a very long time. My first job here in Silicon Valley was a Barca up. The very first start up building knowledge bases for call centers, and I implemented a lot of call centers and a lot of, knowledge processes and tools around the globe. And what I have found over these many years is the single biggest determinant for success of a knowledge management program is the culture of the company. And this survey question asked people to rate their company on a ten point scale with one being share knowledge and others take credit. And as bad as that is, we've all worked in that environment at some point in our career. And a ten is leaders set the example and reward knowledge sharing. And the average last year was a six point one eight, slightly up over the previous year, but not by much. And, you know, if we look at some of these other data points I'm going to show now, the impact of culture on this data is really interesting. And if I slice the data by culture score, like companies that rated themselves a seven, eight, nine, or ten, you start to see some pretty dramatic differences. So one thing everybody's curious about is k Kilometers program staffing and management, and I certainly like to see dedicated, Kilometers authors, companies that say, well, everybody's responsible for knowledge management. The problem with that is no one's responsible for knowledge management. So I do like to see some dedicated authors, some dedicated program managers, and the percentage of companies that offer that is much higher, for the companies that say they have a high culture score. Another thing that, I look for is, you know, if if you do not have any goals, and employee performance, their annual review, around participation in the knowledge management program, you're really sending a subtle message or maybe not so subtle to your employees that you got a lot of things on your plate and Kilometers is not important. So if you refuse to participate in Kilometers, it's not gonna impact your performance review. We don't have any bonus programs around it, and unfortunately, nearly half of companies, don't have any compensation link or performance link, to, activities or outcomes, which would be like producing the highest quality content or the top used knowledge articles. So that's something, you know, a decade ago, we actually saw much higher numbers here, and it's kind of been trending down. And another thing is, program budget. Forty five percent of companies have Kilometers, as a guaranteed part of their permanent budget. Unfortunately, more than half of companies do not. And, you know, that's again something about eighty or ninety percent of companies with high culture scores tend to have dedicated, budget for Kilometers. And the final data point is around are your executives looking at your Kilometers metrics as a part of your operational reviews. And obviously, if Kilometers is an important thing to your executives, and they're acknowledging and rewarding knowledge sharing, they're gonna be looking at those metrics. And, if you see companies that the executives could not care less about those metrics, that tells you a lot, about about the culture scores. So my final slide, I've got some data here on the percentage of members that had budget for knowledge management technology, from the last four years of surveys. And the twenty twenty survey was completed at the end of twenty twenty, and eighty five percent of companies said they had budget in twenty twenty or twenty twenty one, for knowledge management. And I'm thrilled to see that much interest, that much budget, but, you know, the ugly truth is that if you don't get your people, process, and culture right, that technology is really going to have a difficult time achieving the desired results. So try to get more, dedicated staffing both on the program management side and on the knowledge authoring side. And I would really recommend that you survey all of your employees with that culture question. And what I tend to see is, management always says our culture's amazing. Employees rate it, quite a bit lower. And you may find if you've got a lot of geographic offices, maybe some, offices have a little, you know, not as good culture as others. So it's good to, kind of understand if there are pockets, within your organization that maybe need some additional Kilometers coaching or some training or some incentives, to get them to be a part of the program. Well, that is enough from me, and I'm very happy, as I said, to have, OSIsoft here today. And I'd like to turn things over now, to Bonnie Chase, who's who's the director of product marketing for Caveo. Bonnie, take it away. Thanks so much, John. I'm very excited to be here today. You know, knowledge management is a topic that I'm very passionate about. It's what I have my background in. But, you know, looking at this data and and what I'm seeing you share, John, it it it's very obvious that I that many companies have room for growth, and we still have a lot that, you know, we can learn from each other. So that's really why I invited, Alex and Dara from OSIsoft to join us here today. So OSIsoft is a market leading data management platform for industrial operations. They do have, you know, highly technical products and, issues that come through their support team. So first, I'd like to to introduce Alex. Alex, your title is knowledge engineer. Can you tell us a little bit about what that role entails? Yeah. So, I essentially do knowledge management for the tech support department at OSISoft. So, user user guides, help articles, known issues, all of that different types of content. I find, buckets to put it in and places to store it so that people can find it and use it when they need it. And, Derek, you're business analyst now, but you've been, you've been part of this program as well, especially in the in the early stages. Can you tell us a little bit about your role there? And you're on mute. Sorry about that. Okay. Yes. I first started working at OSIsoft, leading their initial knowledge management efforts in the support department many years ago. Later, I became a product owner for our tech support website and search. After we went through our digital transformation about two years ago, I started working in the customer success organization, as a business analyst to help improve our tools and business processes to support both our customers and our internal support organization. So you went through so your team went through a knowledge transformation recently. And can you share a little bit about those challenges that you faced prior to making those changes? Sure. Yeah. Before we went through our digital transformation, we had a lot of challenges with the tools and participation and also the culture around knowledge sharing. So starting with the tools and the environment, we had over ten different repositories that we needed to crawl for our knowledge base, and SharePoint search was a search engine that OSI had licensed. And some of you may know, SharePoint search is really optimized for searching and reporting on assets that live in SharePoint. However, none of our assets were actually in SharePoint, so we had to build many custom connectors to each of our repositories, which required a lot of tuning and maintenance, and we were not able to get good reporting on usage. Secondly, there were concerns around security during our testing, so we needed to set up two separate production environments for our search. There was one search for our external customer facing users, and then there was another search for our internal support engineers. So a huge overhead in maintaining, multiple SharePoint server farms, which consisted of over twenty six servers. The search itself was also, had some issues. For example, there was some issues handling certain syntax. Many of the error messages that people would search for included a negative number, so a minus sign preceding the error number, and the search engine would interpret that minus sign as something that you did not want in your search results, which meant that people were unable to find the very error message that they were looking for. Another issue is that with no partial matching in the search and no auto suggestions. So users really had to know exactly which words to search on to get the right search result. So for us to help our customers with this, we ended up building a large list of synonyms, which was difficult to maintain. So can't connect, cannot connect, won't connect, did not connect. You know? So that could go on forever. Ultimately, because of this poor search experience, many of our customers, and even some of our own internal support engineers would use the public Google search to find answers on our website. So those were just some of the challenges from the tools side. There were also process challenges. This became very clear when customers started complaining that they could not find stuff that they knew was there. And this was partly due to the limitation in the search tool, but it was also partially due to the knowledge management process itself. Our model wasn't working very well. First, there was no incentives or or mandate to create or review knowledge as part of the support engineer's job. It was always treated as something you did when you had extra time, which, of course, nobody did. Too much useful content was getting stuck in the pipeline and not getting published and shared with our customers. And there was a lot of fear around giving, like, the less than perfect answers, so really good and useful knowledge would sit internally, and not get published. The customers knew it was there because when they called us, our support engineers could find it right away. So customers really wanted to self serve, but we were not doing a good job enabling them to do so. And getting them to take the time to create and review knowledge required a lot of hand holding. We had a small knowledge management team, and we would set up regular meetings with our product specialists to go through and review content to get it published. And this worked okay when we were a small company, but it really didn't scale with the growing organization. So it really wasn't until we had a direct support and a mandate to do knowledge management from a new director that we were able to invest in the tools, the people, the processes to support a successful knowledge management rollout. So that pretty much sums up our challenges. Well, I mean, it sounds like you were able to get the support that you needed to make the transition. And and just to kind of summarize your goals here, you know, and and talking with Alex, it seemed like you really needed that single view of of customer data that's one source of truth. Finding a tool that was low maintenance and had more relevant results so that you didn't have to spend so much time tuning, and you're actually getting results that you're looking for. You also mentioned, you know, issues with or concerns about security, and so that's why security based personalization was really important. Exactly. From people and and process perspective, you know, you mentioned you got the leadership support, but you also started implementing knowledge centered service. So I don't know if if you all are familiar with knowledge centered service, but it is a a methodology for capturing knowledge in the flow of work. And then I also have listed here as one of your goals was really to lower time to resolution, when solving cases. So, with this being your goals, Alex, can you talk a little bit about what your current system looks like, and and and talk through now that you've you've kind of rolled out this this knowledge management program, how does this content get created? What does the ecosystem look like? Can you give us just kind of an overview of of all of that? Right. So we wanted a a process that would take, all of the knowledge that was in people's heads that they were using to solve problems day to day, and put it into the knowledge base whenever, you know, they needed whenever they needed to answer a question with their knowledge, they would answer it through an article. And so that's the foundation of KCS is being able to take implicit tacit knowledge and make it explicit in an article so that other people can benefit that without having to come and find the one person who knows the answer to that question. And, once we had that process going to make a larger knowledge base, the larger knowledge base allowed people to use that instead of people, and that's what led to, shorter resolution times. So we had a process problem, and we had a search problem. And we sort of solved them both at the same time by adopting a new knowledge based tool in Salesforce, Coveo as a new, search tool, and KCS, as a new process. And so now we have, three different, portals for knowledge. They're all hooked into the same knowledge base, which is Salesforce, but they're showing up to different audiences. We have an internal portal for our employees, and then the external articles within that knowledge base are served up to the customer portal. Subsegment of that is served up to the community, which also serves as our forum for users outside the company to contribute their knowledge to the knowledge base. And all of this shows up in one search tool, which is Coveo, is fed to the different audiences depending on their permissions and their role in the company or outside of it. And so we're able to unify all of this knowledge to the audience when they need it very easily. And how much content would you say is, is available internally versus, you know, to your customers? Right. So, I think about nine percent is available only internally, and everything else is available externally in some form or another. Great. So you you made this transition. You rolled out your new tools, your new processes. Agents are creating content. And so let's talk a little bit about how you measured, success there and and kind of some of those metrics that you were looking at. Right. So, we started out using the KCS Academy's recommendations for, AQI, which is now called, I think, article checklist or some of the content checklist, I think is that's what they changed the name to. And we also use something called RQI, which was a precursor to, PAR. And then from that data, we focused on metrics that of that were really subsegments of those metrics to, emphasize the value of the knowledge base to support. So in that top right graph, you can see that the breakdown of our cases and whether or not they were linked to no article, which is the pink bar, or a new article, which was created as a part of that case handling process, that's blue, or an existing article in our knowledge base, which is, grains. We started collecting this data about three months after we started the KCS program. So you can see now today, about seventy five of our cases are answered by an article that existed before the case was open. So we're solving a lot more problems using solutions from, the past rather than having to come up with the same solution and reinvent the wheel every single time. And this has led to, time to resolution, improvement of fifty six percent. We've gone from eight point eight days on average in twenty nineteen to three point nine days on average in twenty twenty one. We're also looking at, self some self-service metrics on our website. So we look at no result queries, which is, you know, the user typed something in and nothing came back. Those are less than one percent, and the ones that do exist are usually because of some sort of typo. Right? That's not a problem we can fix with the search engine. Right? So, the next item that we looked at was, click click through rate, which indicates, you know, if somebody does a search, do they click on something? Right? Because if they clicked on something, they found it interesting, probably helped them solve their problem, and that's been pretty high at eighty five percent. So we're answering questions faster internally. We're answering more consistently, and our customers are able to use those answers without even having to call us because of the increased self-service. Yeah. And these these are great numbers. And and when we were talking before, you know, you were mentioning some of the content gap, content gaps that you were looking to fill, and it seemed like before you kind of your content gaps are really because you didn't have content that existed. But then after you rolled out the KCS methodology, people started contributing content. They're actually finding answers now. And so you really your content gap is really small at this point, which is which is great. So let's talk a little bit about, you know, the lessons learned and and the best practices that you'd like to share from this transition on the next slide. Right. So if you want to roll out the KCS methodology, successfully, I would highly recommend you go to the KCS Academy website. You look through the KCS best practices. They're on version six and just follow those. Every time we have strayed away from those best practices, unless we had a really good reason to, it's kind of, it's hurt us rather than helped us, and we've had to kind of go back to what is outlined in those guides. So the KCS best practices that I'm gonna share here, I found especially key, in implementing the project, but are also kind of the hardest ones to accomplish. The first and foremost is you need leadership support. Right? If the people at the top who are in control of the performance reviews of your support engineers, aren't on board with this, then they're not going to, you know, emphasize it. They're not gonna grade it. They're not gonna promote it. So your support engineers want to please their bosses. They wanna do a good job. They're gonna do the things that get them better performance reviews. Right? And that goes back to what was mentioned earlier. The the another thing I've seen in successful KCS programs, including ours, is that you need at least one champion who's doing full time KCS work to sort of drive this program forward. They sort of serve as the central hub for information and decisions, and everybody sort of inherits from them. And then the third, leg for this stool is dedicated coaches. So these are peers of your support engineers who are on board with the KCS idea. They get it. They wanna encourage it. They wanna participate in it. And so you train them on KCS best practices, and then they have regular meetings with their mentees and, review their cases, review their articles to make sure that those cases and articles are in line with your guidelines, your content standard. I would say our our the biggest biggest thing to do with coaches is that you want people to want to do KCS. So when you're coaching, you are not, you need to avoid something called death by a thousand paper cuts, which is if you're going through a content checklist and you're saying, you know, this is wrong. This is wrong. This is wrong. This is wrong. And you do that every single time for every single article. Well, then your mentee is going to have this, impression that no matter what they do, they're always gonna get it wrong. Right? So we sort of, shift that conversation to be sort of mentee led. So the mentee comes forward and is like, you know, I thought, you know, these are the things that I'm struggling with that I need to work on. And then the coach is like, okay. Well, what are some good goals that we could do there? And so the mentee sets their own goals, and the coach is just tracking, you know, are they following those goals? And if those goals aren't sufficient for following, you know, your best practices, your policies and guidelines, the coach sort of corrects that as well. And then the last piece with people is that you really need to focus on the benefits to your frontline engineers. As I mentioned before, you need to make sure that people want to do KCS, which means they need to know that there's gonna be a benefit for all of this effort they're putting into your knowledge base. And to be upfront and honest that it's it's gonna be very hard at the beginning, and the benefits are gonna pay off six months to a year down the road. They are gonna see them, but they have to be patient. K. So at this point, it should be pretty obvious that I recommend you you follow the KCS methodology. When you're getting it rolling, I highly recommend you start with a pilot program. We did not. We rolled all of our tools and our processes out at once in one big launch. That has some pros and cons, but I would say the pilot program is probably the way to go. You wanna find the people who are most excited about this, get them on board, start rolling out the program, find out where the kinks are, what questions are gonna come up, sort of learn from experience what a best design is, and then you implement your larger design, your larger communication, network with the things you've learned from that pilot program. If you do roll it out and just not a lot of people are on board, that's okay. Partial participation is still gonna get you a knowledge base. It's just gonna take longer. Right? So, something that I have seen in other KCS programs is that if you can get about twenty percent of your frontline to participate in KCS or the majority of your frontline to participate some of the time in KCS, then you will have enough knowledge base building up that people can still use those articles. And they'll probably be using the ones that come up most often the most. And that sort of gives you some time back as you start to gain the benefits of knowledge base. And so that gives people more time to do the harder thing of documenting new articles. So as long as you can get above that threshold, you can get to the benefits that KCS promises. And the last piece for the the rollout is that you really have to be clear and communicate. You have to overcommunicate to people. Some people get it immediately. A lot of them are like, that makes a lot of sense. But then actually getting them to change their workflow is very difficult. Getting them to think differently about their job and what is a successful job versus unsuccessful or nonoptimal is maybe a better way to say it. It's hard. It's hard to shift people out of what is normal and routine. So you really have to overcommunicate your expectations. You absolutely need a good search engine for this. You need a passable knowledge base, I will say. If you're looking if you're shopping around for knowledge bases, the Salesforce knowledge base works just fine. I recommend getting a knowledge base with really good version control. That means every time somebody makes a change to an article, the who who changed it, when they changed it, what was the previous version, all of that is captured in an easy to find format. This really helps, it this would have helped us more if we'd had a good version control knowledge base because our product specialists were very nervous about letting our frontline engineers tell our customers how to solve their problems. From their perspective, they only saw the stuff that our frontline struggled with, so they didn't have a very high opinion about what it was our frontline was capable of doing. Having that version control lets them see who is changing what on which articles and why they can then go and talk to that person about why a particular change was made. It helps them trust, both their frontline engineers and the process as a whole as a result if they can see who is changing what and when. Yeah. Oh, one last thing about the tools. Sorry. Before I move on. Don't go crazy with different templates for knowledge types. We started out with eight. We really only need about four. KCS Academy recommends one. Our knowledge base covers more than just, support articles. So that's why we don't follow that particular KCS guideline. But for your support articles, you really only need one type of template, especially when you're starting out. So I would say start simple. It's what you know you must have and sort of branch out from there into what you discover you need as you roll this out. Great. Thank you for sharing those best practices. Looking forward, what do you have coming next? Dara, you wanna take this one? Okay. So, well, we were recently acquired, by Aviva. So, I know we're gonna have a whole new world of knowledge that we're gonna figure out how to incorporate, and perhaps for crawling because we're gonna be supporting products from two different companies in one knowledge base at some point. One of the things that we're gonna wanna be careful about is making sure that the product taxonomy is is consistent across all of our assets because the search needs to be able to roll those up. So that there's gonna be some challenges there that, we're looking forward to. Also, one of my hopes is, in the future that we would be able to extend our knowledge management practices across the organization internally for our own departments, and do search across the enterprise that way, just for people OSIsoft employees or Avivo employees be able to find answers to questions about their employment, their payroll, their HR, accounting, or whatever. Right now, we're very focused on support and services, but I feel like there's a a big potential for for more sharing throughout the company. Yeah. Absolutely. And and that knowledge across the organization is really I I feel like that's a huge topic right now, especially as people are working from home and knowledge is needed both internally and externally. So if anyone listening is is doing that now, feel, connect with connect with Alex and Dara and, give them some tips there. So that's kind of what we had to share today. Really just wanted to share the OSIsoft story. So, at this point, I think, Vanessa, we can take some questions and, yeah, let's see what the audience has to ask. Great. Well, just as a reminder, if you would like to submit a question, please an enter it in the ask a question box in the top left corner of the webinar player, and we'll get through as many as time allows. We do have quite a few questions. So I'm going to jump right in and just pose these questions to our entire panel. And the first question is going to be from Matt, and they ask, can someone comment on the importance of making sure content is open and public versus dated and behind the login? I'm happy to comment on that. So, this is a question that I see a lot because a lot of times what I hear is upper management doesn't want the knowledge base to be shared publicly. Typically, it's really, you know, for a number of different reasons whether it's, you know, they don't want support issues showing up above marketing pages in Google, or they don't want people finding, you know, the problem articles or whatever that reasoning is. I do see it a lot. The way to to the the view that I have on this particular topic is, you know, we shouldn't be holding information back from customers if it is helpful to them. Now, obviously, there are reasons for putting content behind a login, security reasons, you know, other, you know, purse you know, security and then not sharing your product information and things like that. So in those cases, obviously, you can't make your content public. But there are knowledge management tools that allow you to have some content on a page public and the rest secure, so that if you if you are, you know, if your customers are searching in Google, you can still have content surfaced up without having the, the private information showing up as well. So that's something to consider if you're wanting to make your content more publicly available, but your leadership isn't, maybe finding a way to make part of the content, accessible and and and securing the rest of it. If I can just add, I also you know, there's some upsell potential there if you have subscription only content, like, from a customers always see these articles, but they can't get to it because they haven't subscribed, it's gonna boost your subscription rate. So go ahead and index it and let them know it's there. And if there's a, you know, upsell potential, why not take it? Yeah. Okay. Our next question is from Eric, and they ask, how do you recommend linking Kilometers to performance or incentive compensation while keeping Kilometers quality high? Right. So the KCS Academy recommends that you do not, incentivize activities. So that would be things like linking your articles to cases, because then you're gonna get a hundred percent link rate, but what they're linking is not necessarily an article relevant to the case. Or if you you emphasize edits, you're gonna get a whole bunch of edits that don't actually add any value. If you emphasize creation, you're gonna get up a whole bunch of articles that are not very useful. They're very specific. They're not filled out very well. So don't reward activities. We we don't have any concrete rewards like, hey. You're a great author. Here's a trophy. That we don't have that. But we do have coaches who are actively trying to help their mentees improve, and that goes a long way to let people know that they are doing a good job. They're doing what they're supposed to do, and that people are seeing that effort even if it is just their peers. Now those coaches, evaluations do they do go to managers, but the the statistics, the AQI, the RQI, that lies just in the coach's hands. So the coach can be free to grade as they see fit for their mentees. And then, when it comes to review time, the manager goes to the coach and says, hey. How is this person doing? And the coach is like, well, they're doing either okay or, you know, maybe not so great or they're, you know, over the moon about how well they're doing. And so we really sort of abstract lots of numbers and metrics into just sort of a recommendation of, are they meeting expectations, or do they really need to be rewarded? Or, you know, this is a problem that needs to be fixed. Right? And that's that level of detail so far has worked for us, but we are looking at, doing a better job of really highlighting the people who do a good job, above and beyond what is asked of them. I would also put in a plug for OCMF, the open customer metrics framework, which is an open source approach to support metrics that TSIA and a lot of our member companies collaborated on. If you Google OCMF, you'll find it. They've got a module just for knowledge management metrics, and the focus there is on quality, rewarding people who are submitting the best content, the most used content, the most thumbs up content, things like that instead of activity. So check out OCMF. They've got some great suggestions on quality related metrics for rewarding and recognizing employees. Okay. Our next question is from Vigney, and they asked, do you roll it out to all audiences audiences at once, for example, internal and customers, or do you do that individually? We, well, we did. We did roll it out sort of all at once to you know, once it was available internally, it was available externally as well. That's don't do that. So what KCS recommends that you do is you have sort of two states for articles, not validated and validated. So you write the article in its first draft. It stays as not validated. That stuff is kept internal. As that article gets reused, it gets improved. It's a part of the process. Eventually, it reaches a point where either one of your product specialists called publishers in the KTS world, finds it and goes, you know what? This follows the content standard. It's got good information. Ten other people have used it without any problems. We're gonna go ahead and validate that. Becomes public. We kind of launched with the not validated stuff and validated stuff going out to our customers and then put, like, a warning on the not validated because we wanted to emphasize that we were trying as much as possible to help our customers by making all of the information we had available to them. I don't do that. What we found is that, especially at the beginning of KCS, people aren't really comfortable writing articles. The process is new. The tools are new. They weren't familiar with it, and some stuff went out that really shouldn't have. So I recommend having some sort of a a waiting period for articles where they need to be reused a certain number of times before they're made available to your customers. Okay. So let's squeeze in one more question. And let's see. Paul asks, who has been involved in the buying process? Okay. I can take that one. So there was in terms of selecting a product, there were a team of stakeholders from the business side and from the IT side that wrote up the requirements and evaluated the different search engines and vendors. In terms of once that decision was made of which vendor to go with, the buying process was handled by our IT business partner and, the VP of our IT department and our legal department. Okay. Well, I know we still have quite a few questions that we weren't able to answer here live, but unfortunately, we are out of time for today's webinar. We haven't forgotten about you though, and we will make sure to follow-up with you personally. That being said, we have come to the conclusion of today's live webinar. And now just a couple of quick reminders before we sign off for today. There will be an exit survey at the end of today's webinar. Please take a few minutes to provide your feedback on the content and your experience by filling out that brief survey, and a link to the recorded version of today's webinar will be sent out within the next twenty four hours. I'd now like to take this time to thank our presenters, John, Bonnie, Barca, and Alex for delivering an outstanding session. And thank you to everyone for taking the time out of your busy schedules to join us for today's webinar, Knowledge Management Best Practices for a Successful Customer Support Experience, brought to you by Technology and Services Industry Association and sponsored by Coveo. We look forward to seeing you at our next TSIA webinar. Take care, everyone.